Security for spoofed certs #98
Conversation
Require re-application of certificate pinning, mention possibility of further implementation-specific checks.
|
The text on pinning is fine. If the intent is expand on the authentication requirements for alternatives, the first sentence would suffice. I'm concerned that the "additional requirements" you describe here might lead to interoperability problems. If these aren't specified, we are left to guess what the validation requirements are for any given client. I recognize that failure to authenticate an alternative doesn't necessarily translate into a fatal error - the alternative is just not used. However, I'm wondering what the motivation for the change is. |
|
This is from #76, which I should have tagged. You argued against the spec requiring an identical cert, and I agree that synchronization and security of the cert could certainly be an issue. However, the client might already have some data about the certs used by the origin and could reasonably expect some similarity between them. As I said in the issue, I think cautious implementations will probably do something here, and I'd prefer the possibility to be mentioned in the spec so it's something operators will be aware of. |
Text revision based on Yokohama discussion; replaced "implementation-specific" with "other" and removed example.
|
@martinthomson are you ok with this proposal? |
|
Yes, it is what we discussed in the meeting. |
Security for spoofed certs (#98)
Text giving recommendations for guarding against spoofed certs.